Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@poshinchen
Hi could you tell me when this PR will be merged? Because it affects contents of the book and the deadline is the next week. Thanks 🙏

Hi @minorun365 could you update the PR to resolve the conflict? then I can approve and merge!

@poshinchen Rebased onto latest main and resolved conflicts. PTAL 🙏

Conflict resolution summary:

• feat: add context_window_limit to model configs #2176 (BaseModelConfig) — Accepted main side. BedrockConfig now inherits from BaseModelConfig and the import is updated accordingly.

• chore(log): added warning for default model awareness and is subject to change #2164 (default-model warning) — Preserved the warning behavior. The _get_default_model_with_warning() helper was no longer needed (the global. profile removes the region-to-prefix mapping), so the warning is now emitted directly from BedrockModel.__init__ whenever model_id resolves to DEFAULT_BEDROCK_MODEL_ID:

  if self.config.get("model_id") == DEFAULT_BEDROCK_MODEL_ID:
      warnings.warn(
          f"You're using default model '{DEFAULT_BEDROCK_MODEL_ID}', which is subject to change. "
          "Specify a model explicitly to pin the model target.",
          stacklevel=2,
      )

  Two tests (test_init_with_default_model_warns_subject_to_change / test_init_with_custom_model_id_no_default_warning) were added to cover the new warning location.

All bedrock unit tests pass locally (hatch test tests/strands/models/test_bedrock.py → 122 passed). Looking forward to your re-review! 🚀

Oh wait I thought that it was another PR...

So, due to security reason, we would like to set the default region to us. prefix. And the reason why the validation exists is due to the fact that user can overwrite the default model via environment variables.

I think the minimum change would be to just update the model_id.

@poshinchen thanks for the clarification — I now understand the security-driven preference for keeping us. as the validated default. I want to share the regional-availability facts that shape the options here, because I don't think the minimum "just bump the model ID" path works for Sonnet 4.6.

Why simply updating to us.anthropic.claude-sonnet-4-6 is problematic

Per the AWS docs 1, Sonnet 4.6 ships with a different set of geo inference profiles than Sonnet 4 did:

The current _get_default_model_with_warning relies on the apac.* prefix existing. With 4.6, APAC regions outside Australia/NZ (Tokyo, Seoul, Singapore, Mumbai, etc.) have no geo profile at all — only global.*. So keeping us. as the hard-coded default means any user in those regions gets a cross-geography routing error before IAM is even evaluated.

Options I see

1. us.anthropic.claude-sonnet-4-6 + keep the validation logic
   Simplest code diff but silently breaks for Tokyo/Seoul/Singapore/Mumbai/etc. users — they'd need to explicitly set a model_id just to get the SDK to work. Not ideal for a "sensible default."
2. Downgrade default to Sonnet 4.5 (us.anthropic.claude-sonnet-4-5-20250929-v1:0)
   Sonnet 4.5 still has apac.*, so the existing region-to-prefix mapping keeps working unchanged. This buys time but pushes the problem one model generation out — Sonnet 4.7 is likely to follow 4.6's pattern (no apac.*), so we'd revisit this the next time the default gets bumped.
3. global.anthropic.claude-sonnet-4-6 (this PR)
   Works from every Bedrock commercial region out of the box, aligns with what the TypeScript SDK already defaults to, and removes the mapping logic because global.* needs none. The security concern is real but it applies to the default value; users who must stay within a specific geography can explicitly set model_id="us.anthropic.claude-sonnet-4-6" (or pin via env var as today). We could keep a warning that encourages explicit pinning in compliance-sensitive environments.

If the security posture requires staying with us. for the default, option 2 (Sonnet 4.5) looks like the only path that keeps the SDK usable everywhere without breaking APAC users. Option 3 is my preference because it matches the TS SDK and future-proofs against further APAC profile churn, but I understand if the security argument outweighs that.

Happy to update the PR to whichever direction you prefer. What's your read?